IHE Actor Configurations

1 Introduction

The goal of this document is to describe IHE actor configuration including the xml file structure and syntax and semantics of tags. This document uses the examples in the ihetest folder under the root of codebase.

2 Configuration File Structure

We have a sample of configuration files which can be used to test the IHE infrastructure against the IBM test server. The configuration files are in the ihetest folder, which is located in the root folder of a Connect2.0 build (See the following Figure for the file structure). Inside the ihetest folder, there are a bunch of xml configuration files. The starting xml file is IheActors.xml; all the other xml files can be linked from the IheActors.xml. The certs folder in the ihetest contains private key and public certificate used by secure transactions.

3 IheActors.xml -- a Starting Point

The start xml configuration file is IheActors.xml. All other config files should be linked from it.

3.1 Load IheActors.xml

There are two ways to load IheActors.xml:

a. To load and install programmatically, use the following example

ConfigurationLoader loader = ConfigurationLoader.getInstance();

URL url = IBMTest.class.getResource("/ihetest/IheActors.xml");

File file = new File(url.toURI());

loader.loadConfiguration(file, false);

Collection actors = loader.getActorDescriptions();

//reset to add log file

loader.resetConfiguration(actors, "c:\\testlog.xml");

b. To load and install from Connect UI

TBA (ask Samir Jain for now)

3.2 Add a log file,

a. Programmtically, add a filename to the method resetConfiguration as shown in the above code snippet (“c:\\testlog.xml”).

b. From Connect UI, (TBA)

3.3 Tags:

Notes: The xml syntax including tags, attributes and elements are all case-insensitive. But we will try to be consistent across all the configuration files.

Configuration: Each configuration file has a root Configuration tag.

Actorfile: An actorfile specifies actor configuration.

Connectfile: A connectfile contains standardconnection and/or secureconnection configuration.

This is IheActors.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!--Note: This file is the starting point of All the Actor configuration;

all other config files should be linked from here. -->

<!--Each configuration file has a root Configuration tag-->

<Configuration>

<!--A connectfile contains standardconnection and/or secureconnection configuration-->

<!--Defines the configuration of XDS Registry for Document Consumer Actor-->

<connectionfile file="XdsRegistryQueryConnections.xml" />

<!--Defines the configuration of XDS Repository for Document Source Actor -->

<connectionfile file="XdsRepositorySubmitConnections.xml" />

<!--Defines the configuration of PDQ Supplier(PDQ Server) for PDQ Consumer Actor-->

<connectionfile file="PdqServerConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Consumer Actor-->

<connectionfile file="PixManagerConnections.xml" />

<!--Defines the configuration of Audit Repository Server for Audit Client-->

<connectionfile file="AuditRepositoryConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Global Source -->

<connectionfile file="GlobalFeedConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Local Source-->

<connectionfile file="LocalFeedConnections.xml" />

<!-- An actorfile specifies actor configuration-->

<!-- The IBM Non-Secure Actors -->

<actorfile file="IBMActors.xml" />

<!-- The IBM Secure Actors -->

<!--actorfile file="IBMSecureActors.xml" /-->

<!-- The Initiate Non-Secure Actors -->

<!--actorfile file="InitiateActors.xml" /-->

</Configuration>

4 Actor Configuration

There are so far 3 actorfile xml files, namely IBMActors.xml, IBMSecureActors.xml and InitiateActors.xml. The IBMActors defines non-secure Actors against the IBM Test Server and the IBMSecureActors defines secure Actors against the IBM Test Server. You can enable and disable them by uncommenting and commenting o the corresponding actorfile tag in the IheActors.xml as follows.

<!-- The IBM Non-Secure Actors -->

<actorfile file="IBMActors.xml" />

<!-- The IBM Secure Actors -->

<!--actorfile file="IBMSecureActors.xml" /-->

<!-- The Initiate Non-Secure Actors -->

<!--actorfile file="InitiateActors.xml" /-->

4.1 Actor tag:

An actorfile specifies actor configuration. It has name and type attributes, and contains description and connection elements

4.1.1 Attributes:

name - the unique name of this actor

type - the type of this actor. The type has to be one of the following entries

PatientIdentitySource - for PIX Feed transaction,

PixConsumer - for PIX Query transaction,

PdqConsumer - for PDQ Query transaction,

XdsDocumentSource - for XDS Register and Submit transaction,

XdsDocumentConsumer - for XDS Query transaction,

SecureNode - for Audit Trail.

Note: More types will be added after Connectathon 2007.

4.1.2 Elements:

A. description - the description of this actor

B. connection - the connection configuration for this actor

Attribute: consumer - the consumer name of either standardconnection or secureconnection; it must be defined in one of the connectionfile.

Attribute: source - the source name of either standardconnection or secureconnection; it must be defined in one of the connectionfile.

C. audittrail - the audit trail repository configuration.

The following examples are in the IBMActors.xml

<?xml version="1.0" encoding="UTF-8"?>

<Configuration>

<!-- IBM Non-Secure Actors -->

<!-- To enable/disable these actors, comment/uncomment the corresponding actorfile in IheActors.xml -->

<!--The actor tag

Attributes:

name - the unique name of this actor

type - the type of this actor. The type has to be one of the following entries

PatientIdentitySource - for PIX Feed transaction,

PixConsumer - for PIX Query transaction,

PdqConsumer - for PDQ Query transaction,

XdsDocumentSource - for XDS Register and Submit transaction,

XdsDocumentConsumer - for XDS Query transaction,

SecureNode - for Audit Trail.

Elements:

description - the description of this actor

connection - the connection configuration for this actor

Attribute: consumer - the consumer name of either standardconnection or secureconnection;

it must be defined in one of the connectionfile.

Attribute: source - the source name of either standardconnection or secureconnection;

it must be defined in one of the connectionfile.

audittrail - the audit trail repository configuration.

-->

<!-- The Local Feed means that the patient identity information is sent from the PIX Source (in our case, it's Misys Connect) to the PIX Manager. -->

<!-- Local Patient Feed Actor -->

<actor name="lpfibm" type="PatientIdentitySource">

<description>Local Patient Feed IBM</description>

<connection consumer="ibm-local-feed" />

</actor>

<!-- In each Affinity Domain, each patient is assigned a global identity, and this identity is managed by a global identity domain. The Global Feed means that the global patient identity of the same patient is sent from the global identity domain to the PIX Manager. Since we don't have a global identity domain in this test environment, we act as a dummy global identity domain. In the realworld, this actor is not needed.-->

<!-- Global Patient Feed Actor -->

<actor name="gpfibm" type="PatientIdentitySource">

<description>Global Patient Feed IBM</description>

<connection consumer="ibm-global-feed" />

</actor>

<!-- In each Affinity Domain, there is a document registry, and it may or maynot be the same server as the PIX Manager. The document registry uses the global patient identity to store patient information. So this Global Registry Feed means that the global patient identity is sent from the global patient identity domain to the Registry. Since we don't have a global identity domain in the test environment, we act as a dummy global identity domain. In the realworld, this acor is not needed.-->

<!-- Global Registry Patient Feed Actor -->

<actor name="gprfibm" type="PatientIdentitySource">

<description>Global Patient Registry Feed IBM</description>

<connection consumer="ibm-global-registry-feed" />

</actor>

<!-- PIX Manager Actor, used by PIX Query -->

<actor name="pixqueryibm" type="PixConsumer">

<description>Patient ID Query IBM</description>

<connection consumer="ibm-pix-manager" />

</actor>

<!-- This actor is not needed. It is presented here for testing purpose; it tests the

scenario of finding a local patient id from a given global patient id.-->

<!-- Global PIX Query Actor -->

<!--actor name="pixgqueryibm" type="PixConsumer">

<description>Patient ID Global Query IBM</description>

<connection consumer="ibm-global-pix-manager" />

</actor-->

<!--This actor is used for the PDQ Query transaction. The connection consumer describes

the PDQ Server (i.e., the destination that a PDQ Query is sent to). -->

<!-- PDQ Server Actor -->

<actor name="pdqibm" type="PdqConsumer">

<description>Patient PDQ Query IBM</description>

<connection consumer="ibm-pdq-server" />

</actor>

<!--This actor is used for the XDS Provide and Register Document Set transtion.

The connection consumer describes the XDS Document Repository (i.e., the

target that a document set is submitted to).-->

<!-- XDS Repository Submit Actor -->

<actor name="xdsibm" type="XdsDocumentSource">

<description>XDS IBM Repository</description>

<connection consumer="ibm-xds-submit" />

</actor>

<!-- This actor is used for the XDS Query transaction. The connection source

describes the XDS Document Registry (i.e., the source that XDS documents are from). -->

<!-- XDS Registry Query Actor -->

<actor name="xdsqibm" type="XdsDocumentConsumer">

<description>XDS IBM Registry (Query)</description>

<connection source="ibm-xds-query" />

</actor>

<!-- This actor is used for Audit Trail transaction. The audittrail consumer

describes the Audit Respository Server that audit logs are sent to. -->

<!-- Audit Repository Actor -->

<!--actor name="auditibm" type="SecureNode">

<description>IBM AUDIT TRAILS</description>

<audittrail consumer="ibm-arr-bsd" />

<audittrail consumer="log4j_audittrail" />

</actor-->

<!--actor name="localaudit" type="SecureNode">

<description>LOCAL AUDIT</description>

<audittrail consumer="log4j_audittrail" />

</actor-->

</Configuration>

5 Connection Configuration

In the IheActors.xml, there is another type of tag, connectionfile, which specifies the connection details for each actor. So far, we have the following connection files:

<!--A connectfile contains standardconnection and/or secureconnection configuration-->

<!--Defines the configuration of XDS Registry for Document Consumer Actor-->

<connectionfile file="XdsRegistryQueryConnections.xml" />

<!--Defines the configuration of XDS Repository for Document Source Actor -->

<connectionfile file="XdsRepositorySubmitConnections.xml" />

<!--Defines the configuration of PDQ Supplier(PDQ Server) for PDQ Consumer Actor-->

<connectionfile file="PdqServerConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Consumer Actor-->

<connectionfile file="PixManagerConnections.xml" />

<!--Defines the configuration of Audit Repository Server for Audit Client-->

<connectionfile file="AuditRepositoryConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Global Source -->

<connectionfile file="GlobalFeedConnections.xml" />

<!--Defines the configuration of PIX Xreference Manager for PIX Local Source-->

<connectionfile file="LocalFeedConnections.xml" />

5.1 StardardConnection vs. SecureConnection

Each connection file can contain both StandardConnection and SecureConnection. The StandardConnection defines non-secure connetion details, while SecureConnection specifies secure connection details. Each connection referenced by an actor in the actorfiles must have a starandconnection or secureconnection definition with the same connection name.

The main properties in each connection definition include hostname, port and/or urlPath.

The following connection is an example of non-secure XDS Document Consumer actor (for XDS Query)

<standardconnection name="ibm-xds-query">

<!--The host name of the XDS Registry Server-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for XDS Query transaction-->

<port>9080</port>

<!--The URL of XDS Registry-->

<urlPath>/ihii/registry/soap</urlPath>

<!--XdsCodes.xml defines the code set used by Connectathon and the NIST IHEOS-->

<includefile name="XdsCodes.xml" />

<!--XdsMisys.xml contains reusable Misys Configuration for XDS-->

<includefile name="XdsMisys.xml" />

</standardconnection>

In each SecureConnection, the following additional properties have to be specified:

<!--The KEYSTORE tag specifies the location of private key store.-->

<KEYSTORE>certs/EHR_MISYS_KEY.key</KEYSTORE>

<!--The KEYPASS tag specifies the password of private key.-->

<KEYPASS>password</KEYPASS>

<!--The TRUSTSTORE tag specifies the location of trust store.-->

<TRUSTSTORE>certs/EHR_MISYS_TRUST.key</TRUSTSTORE>

<!--The TRUSTPASS tag specifies the password of trust store.-->

<TRUSTPASS>password</TRUSTPASS>

5.2 Includefile Tag

The includefile tag can be used to place a trunk of properties in a separate xml file. The main purpose of the includefile is to reuse some common configuration.

In the above example, <includefile name="XdsMisys.xml" /> mean that the Content of XdsMisys.xml can be used to replace this tag.

5.3 Other Properties

There are a bunch of other properties can be defined in each connection. The main tags to specify these properties are Identifier, EnumMap, StringMap, Property and PropretySet.

5.3.1 Identifier Tag

The identifier tag specifies an identity. It can include 3 elements: NamespaceId, UniversalId and UniversalIdType. There are two ways to specify an Identity: one way is to use NamespceId; the other is to use the combination of UniversalId and UniversalIdType. If both NamespaceId and the combination of UniversalId and UniversalIdType are used, they must be consistent and refer to the same entity.

The following example defines an AssigningAuthrity HIMSS2005.

<Identifier name="AssigningAuthority">

<NamespaceId>HIMSS2005</NamespaceId>

<UniversalId>1.3.6.1.4.1.21367.2005.1.1</UniversalId>

<UniversalIdType>ISO</UniversalIdType>

</Identifier>

The following example defines Misys Sending Applicaiton

<Identifier name="SendingApplication">

<NamespaceId>EHR_MISYS</NamespaceId>

</Identifier>

5.3.2 EnumMap Tag

The EnumMap tag defines a map of Misys Property to the code used in affinity domain.

It contains a class attribute whose value is an enum class defined in Misys Connect. The entry element contains an enum attribute whose value is used by Misys Connect, and a code attribute whose value is used by affinity domain.

The following example maps the XdsFormatCode from the values used by MisysConnect to the codes used by the Connectathon affinity domain.

<enumMap class="XdsFormatCode">

<entry enum="HL7_LAB_25" code="HL7/Lab 2.5"/>

<entry enum="IHE_PDF_10" code="PDF/IHE 1.x"/>

<entry enum="IHE_CDA_10" code="CDA/IHE 1.0"/>

<entry enum="IHE_CDAR2_10" code="CDAR2/IHE 1.0"/>

<entry enum="IHE_CCR_09" code="CCR/IHE 0.9"/>

<entry enum="IHE_PCC_MS_10" code="IHE/PCC/MS/1.0"/>

</enumMap>

5.3.3 StringMap Tag

The StringMap tag defines a map of Misys Property to the code used in affinity domain.

It contains a name attribute whose value is used in Misys Connect. The entry element contains a string attribute whose value is used by Misys Connect, and a code attribute whose value is used by affinity domain. The StringMap is different from EnumMap in that EnumMap has a corresponding enum class defined in Misys Connect, and its size is limited.

The following example maps the facilityCode from the values used by MisysConnect to the codes used by the Connectathon affinity domain.

<stringMap name="facilityCode">

<entry string="EMR" code="Outpatient"/>

<entry string="CPR" code="Hospital Setting"/>

</stringMap>

5.3.4 PropertySet Tag

The PropertySet tag defines a set of properties related to each other.

The following example defines the QueryProperties used by a PDQ Query against the IBM test server.

<PropertySet name="QueryProperties">

<Entry name="Uppercase" value="true"/>

<Entry name="WildcardBefore" value="*"/>

<Entry name="WildcardAfter" value="*"/>

</PropertySet>

5.3.5 CodeTypeTag

The CodeType tag is special type of tag which defines the code set used in affinity domain. The code defined here can be referenced by EnumMap entries and/or StringMap entries.

The following example defines the formatCode used by the Connetathon affinity domain.

<CodeType name="formatCode" classScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d">

<Code code="PDF/IHE 1.x" display="PDF/IHE 1.x" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CDA/IHE 1.0" display="CDA/IHE 1.0" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CDAR2/IHE 1.0" display="CDAR2/IHE 1.0" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CCR/IHE 0.9" display="CCR/IHE 0.9" codingScheme="Connect-a-thon formatCodes"/>

<Code code="HL7/Lab 2.5" display="HL7/Lab 2.5" codingScheme="Connect-a-thon formatCodes"/>

<Code code="IHE/PCC/MS/1.0" display="XDS-MS" codingScheme="Connect-a-thon formatCodes"/>

<!-- added for XDS-I -->

<Code code="1.2.840.10008.5.1.4.1.1.88.59"

display="Key Object Selection Document"

codingScheme="1.2.840.10008.2.6.1"/>

</CodeType>

5.4 PIX – Local Feed Connections

Local Feed means that the patient identity information is sent from the PIX Source (in our case, it's Misys Connect) to the PIX Manager. A Local Feed Connection is used to configure a PIX Manager Server and those properties related to the PIX Feed transaction.

Each Local Feed Connection needs to specify hostname, port, ReceivingApplication, ReceivingFacility, MisysAssigningAuthority, SendingApplication, SendingFacility, IPatientConsumer$CreationReason and Optional DateFimeFormats

An example of LocalFeedConnection

<!-- Local Patient Feed Actor -->

<actor name="lpfibm" type="PatientIdentitySource">

<description>Local Patient Feed IBM</description>

<connection consumer="ibm-local-feed" />

</actor>

<standardconnection name="ibm-local-feed">

<!--The host name of the PIX Manager Server-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for PIX Feed transaction-->

<port>3600</port>

<!--The ReceivingApplication specifies the ID in (MSH-5) for PIX Feed and PIX Query -->

<Identifier name="ReceivingApplication">

<!--There are two ways to specify an ID: One way is to use NamespaceId; the other is to use the combination of UniversalId and UniversalIdType. -->

NamespaceId>PAT_IDENTITY_X_REF_MGR_IBM1</NamespaceId>

</Identifier>

<!--The ReceivingFacility specifies the ID in (MSH-6) for PIX Feed and PIX Query -->

<Identifier name="ReceivingFacility">

<NamespaceId>IBM</NamespaceId>

</Identifier>

<!--The includefile tag specifies an in-line configuration file (i.e. The content in the

LocalMisys.xml can be put here to replace this tag). The main purpose of the

includefile is to reuse some common configuration. -->

<includefile name="LocalMisys.xml" />

</standardconnection>

The LocalMisys.xml is as follows:

<Configuration>

<!-- Use the Misys Authority to sign our IDs for these feeds -->

<!--Required: The MisysAssigningAuthority specifies Misys Patient Identity Domain name.-->

<Identifier name="MisysAssigningAuthority">

<NamespaceId>MIEH</NamespaceId>

</Identifier>

<!--Required: The SendingApplication specifies the ID in (MSH-3) for PIX Feed and PIX Query -->

<Identifier name="SendingApplication">

<NamespaceId>EHR_MISYS</NamespaceId>

</Identifier>

<!--Required: The SendingFacility specifies the ID in (MSH-4) for PIX Feed and PIX Query -->

<Identifier name="SendingFacility">

<NamespaceId>MISYS</NamespaceId>

</Identifier>

<!--Required: IPatientConsumer$CreationReason defines a mapping of patient creation reason

from Misys Connect enumeration to the code used in the Affinity Domain.

The code is used in Section PV1-2 for PIX Feed. -->

<EnumMap class="IPatientConsumer$CreationReason">

<Entry enum="OUTPATIENT_REGISTER" code="O"/>

<Entry enum="INPATIENT_ADMIT" code="I"/>

<Entry enum="INPATIENT_PREADMIT" code="P"/>

</EnumMap>

<!-- Optional: DateTimeFormats

If the following values are supplied as valid Java SimpleDateFormat strings,

they will be used rather than the default formats for HL7 times:

-- BirthDateTime - optional: Format string for birth dates. The

default format is "yyyyMMdd".

-- VisitStartTime - optional: Format string for patient visit start times.

The default format is "yyyyMMddHHmmssZ".

-- EventTimeFormat - optional : Format string for patient event times.

The default format is "yyyyMMddHHmmssZ". -->

<PropertySet name="DateTimeFormats">

<Entry name="VisitStartTime" value="yyyyMMddHHmm"/>

<Entry name="EventTimeFormat" value="yyyyMMddHHmmss"/>

</PropertySet>

<!-- Optional: DefaultRace

If this parameter is supplied it will be sent in PID-10 of PIX Feed.

Normally this will be a code for "Unknown" if it is supplied.

<!-- Property name="DefaultRace" value="WH" -->

</Configuration>

5.5 PIX – Global Feed Connections

In each Affinity Domain, each patient is assigned a global identity, and this identity is managed by a global identity domain. The Global Feed means that the global patient identity of the same patient is sent from the global identity domain to the PIX Manager. Since we don't have a global identity domain in the IBM test environment, we act as a dummy global identity domain. In the real world, this actor is not needed in Misys Connect.

A Global Feed Connection specifies the same properties as Local Feed Connection

An example of GlobalFeedConnection

<!-- Global Patient Feed Actor -->

<actor name="gpfibm" type="PatientIdentitySource">

<description>Global Patient Feed IBM</description>

<connection consumer="ibm-global-feed" />

</actor>

<standardconnection name="ibm-global-feed">

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<port>3600</port>

<Identifier name="ReceivingApplication">

<NamespaceId>PAT_IDENTITY_X_REF_MGR_IBM1</NamespaceId>

</Identifier>

<Identifier name="ReceivingFacility">

<NamespaceId>IBM</NamespaceId>

</Identifier>

<includefile name="GlobalMisys.xml" />

</standardconnection>

The GlobalMisys.xml is as follows:

<Configuration>

<!-- Use the Global Authority to sign our IDs for these feeds -->

<Identifier name="MisysAssigningAuthority">

<!--There are two ways to specify an ID: One way is to use NamespaceId; the other

is to use the combination of UniversalId and UniversalIdType. If both approches are used, they must be consistent and refer to the same entity.-->

<NamespaceId>HIMSS2005</NamespaceId>

<UniversalId>1.3.6.1.4.1.21367.2005.1.1</UniversalId>

<UniversalIdType>ISO</UniversalIdType>

</Identifier>

<Identifier name="SendingApplication">

<NamespaceId>OTHER_KIOSK</NamespaceId>

</Identifier>

<Identifier name="SendingFacility">

<NamespaceId>HIMSSSANDIEGO</NamespaceId>

</Identifier>

<EnumMap class="IPatientConsumer$CreationReason">

<Entry enum="OUTPATIENT_REGISTER" code="O"/>

<Entry enum="INPATIENT_ADMIT" code="I"/>

<Entry enum="INPATIENT_PREADMIT" code="P"/>

</EnumMap>

<PropertySet name="DateTimeFormats">

<Entry name="VisitStartTime" value="yyyyMMddHHmm"/>

<Entry name="EventTimeFormat" value="yyyyMMddHHmmss"/>

</PropertySet>

<!-- Property name="DefaultRace" value="WH" -->

</Configuration>

5.6 PIX – Global Registry Feed Connections

In each Affinity Domain, there is a document registry, and it may or may not be on the same server as the PIX Manager. The document registry uses the global patient identity to store patient information. So this Global Registry Feed means that the global patient identity is sent from the global patient identity domain to the Registry. Since we don't have a global identity domain in the test environment, we act as a dummy global identity domain. In the real world, this actor is not needed in Misys Connect.

An example of Registry GlobalFeedConnection, which is similar to GloablFeedConnetion.

<!-- Global Registry Patient Feed Actor -->

<actor name="gprfibm" type="PatientIdentitySource">

<description>Global Patient Registry Feed IBM</description>

<connection consumer="ibm-global-registry-feed" />

</actor>

<standardconnection name="ibm-global-registry-feed">

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<port>2100</port>

<Identifier name="ReceivingApplication">

<NamespaceId>PAT_IDENTITY_X_REF_MGR_IBM1</NamespaceId>

</Identifier>

<Identifier name="ReceivingFacility">

<NamespaceId>IBM</NamespaceId>

</Identifier>

<includefile name="GlobalMisys.xml" />

</standardconnection>

5.7 PIX – PIX Manager Connections

A PIX Manager Connection is used to configure a PIX Manager Server and those properties related to the PIX Query transaction.

Each PIX manager needs to specify hostname, port, ReceivingApplication, ReceivingFacility, SendingApplication, SendingFacility, either Misys Assigning Authority or Assigning Authority, and PIXQueryName.

An example of PixManagerConnection

<!-- PIX Manager Actor, used by PIX Query -->

<actor name="pixqueryibm" type="PixConsumer">

<description>Patient ID Query IBM</description>

<connection consumer="ibm-pix-manager" />

</actor>

<standardconnection name="ibm-pix-manager">

<!--The host name of the PIX Manager Server-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for PIX Query transaction-->

<port>3600</port>

<Identifier name="ReceivingApplication">

<NamespaceId>PAT_IDENTITY_X_REF_MGR_IBM1</NamespaceId>

</Identifier>

<Identifier name="ReceivingFacility">

<NamespaceId>IBM</NamespaceId>

</Identifier>

<includefile name="PixMisys.xml" />

</standardconnection>

The PixMisys.xml is as follows:

<Configuration>

<!--MisysAssigningAuthority (Identifier) optional:

Specifies the Misys Assigning Authority used by this actor. It is used to identify the Misys Assigning Authority to the PIX manager and to pull out the Misys Unique ID from the returned patient IDs. If it is not supplied, no Misys ID is pulled out of the returned identifier list. (It is not a good idea to leave this value unspecified). Either this parameter or the AssigningAuthority must be supplied. -->

<Identifier name="MisysAssigningAuthority">

<NamespaceId>MIEH</NamespaceId>

</Identifier>

<!--AssigningAuthority (Identifier) optional:

Specifies the preferred ID to send to this PIX manager when trying to cross reference a patient. If this parameter is not specified then the actor cannot cross reference a patient that has no Misys Unique ID. Either this parameter or the MisysAssigningAuthority must be supplied. -->

<!--Identifier name="AssigningAuthority">

<NamespaceId></NamespaceId>

</Identifier-->

<!--Required: The SendingApplication specifies the ID in (MSH-3) for PIX Feed and PIX Query -->

<Identifier name="SendingApplication">

<NamespaceId>EHR_MISYS</NamespaceId>

</Identifier>

<!--Required: The SendingFacility specifies the ID in (MSH-4) for PIX Feed and PIX Query -->

<Identifier name="SendingFacility">

<NamespaceId>MISYS</NamespaceId>

</Identifier>

<!--PixQueryName - (PropertySet) required:

This parameter specifies the query name information to be included in the HL7

message(QPD-1). The required parts are:

identifier - (String) required: A symbolic identifier for the query

text - (String) required: A text string given the query name

codingsystem - (String) required: The name of the coding system for this identifier -->

<PropertySet name="PixQueryName">

<Entry name="identifier" value="QRY_1001"/>

<Entry name="text" value="Query for Corresponding Identifiers"/>

<Entry name="codingSystem" value="IHEDEMO"/>

</PropertySet>

</Configuration>

5.8 PDQ – PDQ Server Connections

A PDQ Server Connection is used to specify a PDQ Server and those properties related to the PDQ Query transaction.

Each PDQ Connection needs to specify hostname, port, ReceivingApplication, ReceivingFacility, SendingApplication, SendingFacility, either MisysAssigningAuthority or AssigningAuthority, PdqQueryName, optional QueryField and optional QueryProperties.

An example of PDQ Connection

<!-- PIX Manager Actor, used by PIX Query -->

<actor name="pixqueryibm" type="PixConsumer">

<description>Patient ID Query IBM</description>

<connection consumer="ibm-pix-manager" />

</actor>

<standardconnection name="ibm-pdq-server">

<!--The host name of the PDQ Supplier Sever-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for PDQ Query transaction-->

<port>3600</port>

<!--The ReceivingApplication defines the ID in (MSH-5) for PDQ Query -->

<Identifier name="ReceivingApplication">

<NamespaceId>OTHER_KIOSK</NamespaceId>

</Identifier>

<!--The ReceivingFacility defines the ID in (MSH-6) for PDQ Query -->

<Identifier name="ReceivingFacility">

<NamespaceId>HIMSSSANDIEGO</NamespaceId>

</Identifier>

<includefile name="PdqMisys.xml" />

</standardconnection>

The PdqMisys.xml is as follows:

<Configuration>

<!--Optional: The MisysAssigningAuthority specifies Misys Patient Identity Domain name. It is used to pull out the Misys Unique ID from the returned patient IDs. If it is not supplied, no Misys ID is pulled out of the returned identifier list. (It is not a good idea to leave this value unspecified). -->

<Identifier name="MisysAssigningAuthority">

<NamespaceId>MIEH</NamespaceId>

</Identifier>

<!--AssigningAuthority (Identifier) optional:

Specifies that this actor only return patient IDs from this assigning authority (and the Misys authority if it is defined). If this parameter is not specified then the

actor will ask for all known IDs from the PDQ server. -->

<!--Identifier name="AssigningAuthority">

<NamespaceId></NamespaceId>

</Identifier-->

<!--Required: The SendingApplication specifies the ID in (MSH-3) for PDQ Query -->

<Identifier name="SendingApplication">

<NamespaceId>EHR_MISYS</NamespaceId>

</Identifier>

<!--Required: The SendingFacility specifies the ID in (MSH-4) for PDQ Query -->

<Identifier name="SendingFacility">

<NamespaceId>MISYS</NamespaceId>

</Identifier>

<!-- PdqQueryName - (PropertySet) required:

This parameter specifies the query name information to be included in the HL7

message (QPD-1). The required parts are:

identifier - (String) required: A symbolic identifier for the query

text - (String) required: A text string given the query name

codingsystem - (String) required: The name of the coding system for this identifier -->

<PropertySet name="PdqQueryName">

<Entry name="identifier" value="QRY_PDQ_1001"/>

<Entry name="text" value="Query By Name"/>

<Entry name="codingSystem" value="IHEDEMO"/>

</PropertySet>

<!--MaximumChunkSize - (Property int) optional:

Specifies the maximum number of patients that should be returned by a single

query. The actor will keep making continuation queries off this size until

the desired number of patients are retrieved. By default the chunk size (-1) is

unlimited. -->

<!--Property name="MaximumChunkSize" value="-1"/-->

<!-- KeepContinuationAlive - (Property boolean) optional:

If multiple contiuations are required they will all be made over a single

socket if this property is "true". If "false", multiple socket connections

will be made. By default this parameter is "true". -->

<!--Property name="KeepContinuationAlive" value="true"/-->

<!-- QueryFields - (PropertySet) optional:

This property set specifies which HL7 parameters should be excluded from a

query even if a value is supplied. Some PDQ servers may not properly handle

some fields and they should simply not be sent. Each entry name specifies a

field id like "PID.3.1" or "PID.5.2" and the entry value is "false" to exclude

the value and "true" to include it (if it has a value in the query). The

default for all fields is "true". -->

<PropertySet name="QueryFields">

<Entry name="PID.3.1" value="true"/> <!--Enable search by Patient ID-->

</PropertySet>

<!--QueryProperties - (PropertySet) optional:

This set of properties specifies global characteristics for queries to the PDQ

server over this connection. The allowed parts are:

Uppercase - (boolean) optional: If this value is "true" all values sent are

converted to uppercase. The default is false (meaning no conversion).

Lowercase - (boolean) optional: If this value is "true" all values sent are

converted to lowercase. The default is false (meaning no conversion). If both Uppercase

and Lowercase are supplied, uppercase will be used.

WildcardAfter - (String) optional: Specifies the wildcard value this connection expects at the end of a value. If this value is not supplied no wildcard will be used at the end of a value, no matter what the user or Misys Connect expects.

WildcardBefore - (String) optional: Specifies the wildcard value this connection expects at the end of a value. If this value is not supplied no wildcard will be used at the beginning of a value, no matter what the user or Misys Connect expects. -->

<PropertySet name="QueryProperties">

<Entry name="Uppercase" value="true"/>

<Entry name="WildcardBefore" value="*"/>

<Entry name="WildcardAfter" value="*"/>

</PropertySet>

<!--QueryFieldMisysNames - (PropertySet) optional:

This property set maps field ids (ie. PID.3,1 and PID.5.2) to the field names for these values in the Misys Connect Query Design Properties file. Each field has a built-in default but these can be overridden using this property set. This is used to look up default wildcard usage in Misys Connect. -->

<!--PropertySet name="QueryFieldMisysNames">

<Entry name="PID.5.1" value=""/>

<Entry name="PID.5.2" value=""/>

<Entry name="PID.5.3" value=""/>

</PropertySet-->

</Configuration>

5.9 XDS – XDS Repository Submit Connections

A XDS Repository Submit Connection is used to specify a XDS Repository Server and those properties related to the Document Submission transaction.

An example of XDS Repository Submit Connection

<!-- XDS Repository Submit Actor -->

<actor name="xdsibm" type="XdsDocumentSource">

<description>XDS IBM Repository</description>

<connection consumer="ibm-xds-submit" />

</actor>

<standardconnection name="ibm-xds-submit">

<!--The host name of the XDS Repository Server-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for XDS Provide and Register transaction-->

<port>9080</port>

<!--The URL of XDS Repository-->

<urlPath>/IHIIRepository/SubmissionSetReceiver</urlPath>

<includefile name="XdsCodes.xml" />

<includefile name="XdsMisys.xml" />

</standardconnection>

The XdsMisys.xml is as follows:

<Configuration>

<!-- Global XDS configuration parameters -->

<!--AssigningAuthority (Identifier) required:

Specifies the Assigning Authority used by this registry/repository. It is used to encode the appropriate Patient ID for a document submission. -->

<Identifier name="AssigningAuthority">

<NamespaceId>HIMSS2005</NamespaceId>

<UniversalId>1.3.6.1.4.1.21367.2005.1.1</UniversalId>

<UniversalIdType>ISO</UniversalIdType>

</Identifier>

<!-- Misys specific XDS configuration parameters -->

<!-- MisysAssigningAuthority (Identifier) required:

Specifies the Misys Assigning Authority used by this actor. It is used to

encode the Misys Unique ID for a patient in the submission set.-->

<Identifier name="MisysAssigningAuthority">

<NamespaceId>MIEH</NamespaceId>

</Identifier>

<!--XdsClassCode (EnumMap) required for XDS Source, optional for XDS Consumer:

This EnumMap describes the mapping from internal Misys Connect XdsClassCode enum codes to class code values appropriate for this registry/repository. For XDS Consumer, if an enum map entry is not supplied, its document class codes will be 'UNKNOWN'. (It is not a good idea to leave some entries unspecified) -->

<enumMap class="XdsClassCode">

<entry enum="DISCHARGE_SUMMARY" code="Discharge summarization"/>

<entry enum="REFERRAL_SUMMARY" code="Transfer of care referral"/>

</enumMap>

<!--XdsFormatCode (EnumMap) required for XDS Source, optional for XDS Consumer:

This EnumMap describes the mapping from internal Misys Connect XdsFormatCode enum codes to format code values appropriate for this registry/repository. For XDS Consumer, if an enum map entry is not supplied, its document format codes will be

'UNKNOWN'. (It is not a good idea to leave some entries unspecified) -->

<enumMap class="XdsFormatCode">

<entry enum="HL7_LAB_25" code="HL7/Lab 2.5"/>

<entry enum="IHE_PDF_10" code="PDF/IHE 1.x"/>

<entry enum="IHE_CDA_10" code="CDA/IHE 1.0"/>

<entry enum="IHE_CDAR2_10" code="CDAR2/IHE 1.0"/>

<entry enum="IHE_CCR_09" code="CCR/IHE 0.9"/>

<entry enum="IHE_PCC_MS_10" code="IHE/PCC/MS/1.0"/>

</enumMap>

<!--XdsTypeCode (EnumMap) required for XDS Source, optional for XDS Consumer:

This EnumMap describes the mapping from internal Misys Connect XdsTypeCode enum codes to type code values appropriate for this registry/repository. For XDS Consumer,

if an enum map entry is not supplied, its document type codes will be 'UNKNOWN'. (It is not a good idea to leave some entries unspecified) -->

<enumMap class="XdsTypeCode">

<entry enum="DISCHARGE_SUMMARY" code="18842-5"/>

<entry enum="REFERRAL_SUMMARY" code="11510-5"/>

</enumMap>

<!--XdsContentCode (EnumMap) required for XDS Source:

This EnumMap describes the mapping from internal Misys Connect XdsContentCode enum codes to type code values appropriate for this registry/repository. -->

<enumMap class="XdsContentCode">

<entry enum="DISCHARGE_SUMMARY" code="Discharge summarization"/>

<entry enum="REFERRAL_SUMMARY" code="Transfer of care referral"/>

</enumMap>

<!--facilityCode (StringMap) optional:

This StringMap describes a mapping from internal Misys Connect facility code values to healthcare facility code values appropriate for this registry/repository. If this string map is not supplied, healthcare facility codes will be taken untranslated. -->

<stringMap name="facilityCode">

<entry string="EMR" code="Outpatient"/>

<entry string="CPR" code="Hospital Setting"/>

</stringMap>

<!--practiceCode (StringMap) optional:

This StringMap describes a mapping from internal Misys Connect practice code values to practice setting code values appropriate for this registry/repository. If this map is not supplied, values will be taken untranslated.-->

<!-- stringMap name="practiceCode" -->

<!--sourceId {StringMap} required for XDS Source:

This StringMap describes a mapping from internal Misys Connect document source code values to source code code values appropriate for this registry/repository. -->

<stringMap name="sourceId">

<entry string="EMR-MISYSCONNECT" code="1.3.6.1.4.1.21367.2006.1.2.122" />

</stringMap>

<!--confidentialityCode (StringMap) required for XDS Source, optional for XDS Consumer: This StringMap describes a mapping from internal Misys Connect confidentiality code values to confidentiality code values appropriate for this registry/repository. For XDS Consumer, If this string map is not supplied, confidentiality codes will be taken directly from the document metadata and translated to a boolean value. Ie. only if the raw value is "true" will the patient be marked as confidential.-->

<stringMap name="confidentialityCode">

<entry string="true" code="S"/>

<entry string="false" code="N"/>

</stringMap>

</Configuration>

The XdsCodes.xml is as follows:

<!-- This file is taken from the NIST IHEOS project: http://hcxw2k1.nist.gov/XdsDocs/AffinityDomain/codes.xml.

Document : code.xml

Created on : October 13, 2004, 2:51 PM

Author : bill

Description:

Acceptable values for XDS Codes in the 2006 Connectathon

These values have not been vetted by the Connectathon committee yet, but

these are the values used last year.

-->

<Codes>

<CodeType name="contentTypeCode" classScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500">

<Code code="Communication" display="Communication" codingScheme="Connect-a-thon contentTypeCodes"/>

……

</CodeType>

<CodeType name="classCode" classScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a">

<Code code="Communication" display="Communication" codingScheme="Connect-a-thon classCodes"/>

……

</CodeType>

<CodeType name="confidentialityCode" classScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f">

<Code code="C" display="Celebrity" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="D" display="Clinician" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="I" display="Individual" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="N" display="Normal" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="R" display="Restricted" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="S" display="Sensitive" codingScheme="Connect-a-thon confidentialityCodes"/>

<Code code="T" display="Taboo" codingScheme="Connect-a-thon confidentialityCodes"/>

</CodeType>

<CodeType name="formatCode" classScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d">

<Code code="PDF/IHE 1.x" display="PDF/IHE 1.x" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CDA/IHE 1.0" display="CDA/IHE 1.0" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CDAR2/IHE 1.0" display="CDAR2/IHE 1.0" codingScheme="Connect-a-thon formatCodes"/>

<Code code="CCR/IHE 0.9" display="CCR/IHE 0.9" codingScheme="Connect-a-thon formatCodes"/>

<Code code="HL7/Lab 2.5" display="HL7/Lab 2.5" codingScheme="Connect-a-thon formatCodes"/>

<Code code="IHE/PCC/MS/1.0" display="XDS-MS" codingScheme="Connect-a-thon formatCodes"/>

<!-- added for XDS-I -->

<Code code="1.2.840.10008.5.1.4.1.1.88.59"

display="Key Object Selection Document"

codingScheme="1.2.840.10008.2.6.1"/>

</CodeType>

<CodeType name="healthcareFacilityTypeCode" classScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1">

<Code code="Home" display="Home" codingScheme="Connect-a-thon healthcareFacilityTypeCodes"/>

……

</CodeType>

<CodeType name="practiceSettingCode" classScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead">

<Code code="Anesthesia" display="Anesthesia" codingScheme="Connect-a-thon practiceSettingCodes"/>

……

</CodeType>

<CodeType name="codeList" classScheme="urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5">

<Code code="Anesthesia" display="Anesthesia" codingScheme="Connect-a-thon codeList"/>

……

</CodeType>

<CodeType name="typeCode" classScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983">

<Code code="34096-8" display="Nursing Home Comprehensive History and Physical Note" codingScheme="LOINC"/>

……

</CodeType>

<CodeType name="mimeType">

<Code code="application/pdf"/> <!-- used only by ACC, I think -->

<Code code="text/x-cda-r2+xml"/> <!-- XDS-MS -->

<Code code="text/xml"/> <!-- Used by CDA R2 -->

<Code code="application/x-hl7"/> <!-- HL7 lab -->

<!-- added for XDS-I -->

<Code code="application/dicom"/>

<Code code="text/plain"/>

<Code code="multipart/related"/>

</CodeType>

</Codes>

5.10 XDS – XDS Registry Query Connections

A XDS Repository Submit Connection is used to specify a XDS Registry Server and those properties related to the Document Query transaction.

An example of XDS Registry Query Connection

<!-- XDS Registry Query Actor -->

<actor name="xdsqibm" type="XdsDocumentConsumer">

<description>XDS IBM Registry (Query)</description>

<connection source="ibm-xds-query" />

</actor>

<standardconnection name="ibm-xds-query">

<!--The host name of the XDS Registry Server-->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for XDS Query transaction-->

<port>9080</port>

<!--The URL of XDS Registry-->

<urlPath>/ihii/registry/soap</urlPath>

<!--XdsCodes.xml defines the code set used by Connectathon and the NIST IHEOS-->

<includefile name="XdsCodes.xml" />

<!--XdsMisys.xml contains reusable Misys Configuration for XDS-->

<includefile name="XdsMisys.xml" />

</standardconnection>

The XdsMisys.xml and XdsCodes.xml are the same as those used in XDS Repository Submissit Connections.

5.11 ATNA – Audit Repository Connections

An Audit Repository Connetion is used to specify an Audit Repository Server and those properties related to the Audit Trail transaction.

An example of Audit Trail Connection

<!-- Audit Repository Actor -->

<actor name="auditibm" type="SecureNode">

<description>IBM AUDIT TRAILS</description>

<audittrail consumer="ibm-arr-bsd" />

<!--audittrail consumer="log4j_audittrail" /-->

</actor>

<standardconnection name="ibm-arr-bsd">

<!--The hostname for the audit repository sever -->

<hostname>ibmod235.dal-ebis.ihost.com</hostname>

<!--The port for BSD log-->

<port>514</port>

<!--Specifies the type of the log. Three types are possible:

1. BSD SYSLOG -- Send Audit Trail using RFC 3164;

2. RELIABLE SYSLOG -- Send Audit Trail using RFC 3195;

3. LOG4J LOGGER -- Send Audit Trail to local host for debug purpose. -->

<Property name="TYPE" value="BSD SYSLOG" />

<!--Specifies the properties of the local host.-->

<PropertySet name="localhost">

<!--The machine name-->

<entry name="MACHINENAME" value="misys1" />

<!--The host name-->

<entry name="HOSTNAME" value="misys1" />

<!--The ip address of the local machine -->

<entry name="IP" value="10.242.0.44" />

<!--The web site of the application-->

<entry name="SITE" value="MISYS" />

<!--The source of the application-->

<entry name="SOURCE" value="EHR_MISYS" />

<!--The application name-->

<entry name="APPNAME" value="EHR_MISYS" />

</PropertySet>

<!--Specifies the properties of ParticipantObject used in the log message.-->

<propertyset name="ParticipantObject">

<!--Optional: Defines the format patient name. Default is standard, HL7 is a good option.-->

<entry name="PatientNameEncoding" value="HL7" />

<!--Optional: Defines the format patient id. Default is standard, HL7 is a good option.-->

<entry name="PatientIdEncoding" value="HL7" />

<!--OPtional: The encoding to use for the document. Default is to not use the document id.

Add "DocumentId" or something to enable it. -->

<entry name="DocumentIdType" value="DocumentId" />

</propertyset>

<!--Optional: If MisysAssigningAuthority is specified, misys patient id

is used if AssigningAuthority is not specified. -->

<Identifier name="MisysAssigningAuthority">

<NamespaceId>MIEH</NamespaceId>

</Identifier>

<!--OPtional: If AssigningAuthority is specified, the patient id in

this AssigningAuthority is used. AssigningAuthority overrides MisysAssigningAuthority. -->

<Identifier name="AssigningAuthority">

<NamespaceId>HIMSS2005</NamespaceId>

<UniversalId>1.3.6.1.4.1.21367.2005.1.1</UniversalId>

<UniversalIdType>ISO</UniversalIdType>

</Identifier>

</standardconnection>